1. Field of the Invention
Embodiments of the present invention generally relate to computer programming for graphics processing systems. More specifically, embodiments of the invention relate to techniques for accessing a texture buffer object using a graphics library.
2. Description of the Related Art
Over the past decade, the cost of adding on-chip logic to processors has substantially decreased. Consequently, certain types of processors, such as advanced graphics processing units (GPUs), now include functionality not previously available in earlier GPU designs. For example, a GPU may include multiple texture image units used to store references to texture maps used in graphics rendering operations. One benefit of this new capability is that more efficient texture mapping operations and the like may now be performed on the GPU, thereby increasing overall performance in the graphics pipeline.
To fully realize additional processing capabilities of advanced GPUs, as much GPU functionality as possible needs to be exposed to graphics application developers. Among other things, doing so enables graphics application developers to tailor their shader programs to optimize the way GPUs process graphics scenes and images. Exposing new GPU processing capabilities to graphics application developers requires that the application programming interface (API) be configured with new calls and libraries that make new features and functionalities directly accessible by developers.
Graphics APIs typically expose an interface to graphics application developers that enables an application executing on the host CPU to load image data, in the form of one or more texture maps, into GPU local memory for greater access and processing efficiency by the GPU. Texture map data is commonly represented as one or more intensity values per texture element, called a “texel.” For example, a texel may include a single intensity value per texel. Alternately, a texel may include four values, corresponding to red, green and blue intensity, and opacity. Each value within a texel is commonly represented using either a floating-point value, such as a standard 32-bit floating-point number, or a fixed-point normalized value. For example, an 8-bit normalized value includes 256 codes, ranging from 0x00 to 0xFF, where 0x00 corresponds to a floating-point value of “0.0” and 0xFF corresponds to a floating-point value of “1.0.” Each incremental code between 0x00 and 0xFF corresponds to 255 increasing floating-point values.
Some prior art graphics APIs provide a set of specific calls used to load and access data from a texture map. Typically, API calls may be used to load a texture map into local memory that is then accessed by a shader engine during rendering operations. In some cases, before the shader engine, which executes the instructions of a shader program, accesses a texture map, the texture map needs to be set to an “active” state for the rendering pipeline. The graphics hardware typically allows a developer to specify an active set of texture maps to use in rendering operations. However, if the developer changes shader programs, then the set of active texture maps may need to be specified again, even if intervening shader programs do not use a texture of that type. Similarly, if a developer desires to use different texture maps for the same shader program, than the developer may have to set an active map each time a different texture map is needed.
Moreover, to even provide this functionality may require multiple data copies to load data into the GPU. Data output from a graphics rendering pipeline is copied into a frame buffer, and then this data is copied from the frame buffer to other portions of memory. Depending on the configuration of a particular graphics hardware device, the process may require the data to also be copied to memory managed by the CPU and then passed back to the local memory of the graphics hardware.
Additionally, conventional textures are accessed by floating-point texture coordinates and are “typed” with a texel format that must be followed whenever the texture is accessed. For a one-dimensional (1D) array of textures, this approach fails to accurately represent the texture map as a set of individual, discrete texels. This formatting requirement limits the amount of memory available for a texture. For example, using 32-bit floating-point texture coordinates would limit conventional 1D textures to an image size of roughly 2^24 pixels. Linear filtering makes the maximum practical size with the prior art even smaller. Filtering allows a weighted average between two neighboring texels to be determined, using the floating-point coordinate to generate a filtering weight. However, the larger an image, the less precision available for weights. For example, if an image had 2^24 texels, each texel may be represented directly, but the 32-bit floating-point coordinates would leave no bits for weights. For example, there is no 32-bit floating point number between 2^24-1 and 2^24-2.
As the foregoing illustrates, what is needed in the art is a mechanism to specify and access texture maps that provides greater efficiency and flexibility than prior art techniques.